home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1288 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.7 KB
  1. From: Julian Reschke <reschke@GOEDEL.UNI-MUENSTER.DE>
  2. Subject: Dxreaddir (1/2)
  3. Date: Mon, 25 Apr 94 12:35:51 MET DST
  4.  
  5. New systemcall Dxreaddir (?)(!)
  6. -------------------------------
  7.  
  8. We already discussed that, with no result. Problem: the current model of 
  9. the directory operations requires that you make two calls (Dreaddir + 
  10. Fxattr) for every file in a directory. Let's recall the arguments:
  11.  
  12. `The current API reflects what POSIX documents and what is needed for a 
  13. straighforward implemention of opendir/readdir/closedir.'
  14.  
  15. This is right, but POSIX 1003.1 is the documentation of the C bindings, 
  16. not necessarily an OS interface. There's no reason why an operating system 
  17. shouldn't provide more efficient services which could then be used by the 
  18. C library to implement opendir/readdir/closedir/stat.
  19.  
  20. `The path lookup in the subsequent Fxattr call could be sped up by caching 
  21. file cookies.'
  22.  
  23. Very well. Obviously it's not that easy, otherwise somebody would have 
  24. done it already. And, even if Fxattr would be made faster, it will *still* 
  25. be faster just to make one call instead of two.
  26.  
  27.  
  28. This is why I've added the new system call:
  29.  
  30. Dxreaddir (short lngth, long dirh, char *buf, XATTR *xap, long *xr);
  31.  
  32. It works just like calls to Dreaddir and Fxattr. In my test application 
  33. (find), the time to walk through my C partition dropped from 17 seconds to 
  34. 7 seconds. Not bad for ~20 new lines in the kernel... (with most of them 
  35. comments and declarations).
  36.  
  37. Some more thoughts:
  38.  
  39. - Dxreaddir doesn't change the FS interface.
  40.  
  41. - Dxreaddir still allows to separately detect failures to read the
  42.   directory entry (Dreaddir) from failures to read the 'inode' (Fxattr), 
  43.   because the return value of the second operation is stored in a separate 
  44.   return code.
  45.  
  46. - Dxreaddir doesn't follow symbolic links. Reasons for that (besides 'keep 
  47.   it simple'): following the link requires new lookups. If the caller 
  48.   needs the 'stat' type information *and* the file was a symbolic link, he 
  49.   can still call Fxattr to get what he needs.
  50.  
  51. - Even if this shouldn't be implemented in MiNT (WHY not?), it would still 
  52.   be good to *define* such an OS call. Other operating system writers 
  53.   might want to support it :-)
  54.  
  55. - The FAT file system is not the only FS that stores the file attributes 
  56.   along with the names (and in this case, Dxreaddir will have the largest 
  57.   gains). Just take a look at a CD ROM. And with the Chicago FS -- that's 
  58.   what people will want to have on removable media for data transfers with 
  59.   the DOS world -- we'll still have no inodes and links, but long names.
  60.  
  61.  
  62.  
  63. -- 
  64. ---------------------------------------------------
  65. Julian F. Reschke, Hensenstr. 142, D-48161 Muenster
  66.  eMail: reschke@math.uni-muenster.de jr@ms.maus.de
  67. ___________________________________________________
  68.